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Abstract

   This document creates a new IANA registry for tracking cost modes
   supported by the Application-Layer Traffic Optimization (ALTO)
   Protocol.  Also, this document relaxes a constraint that was imposed
   by the ALTO specification on allowed cost mode values.

   This document updates RFC 7285.
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1.  Introduction

   The cost mode attribute indicates how costs should be interpreted
   when communicated as described in "Application-Layer Traffic
   Optimization (ALTO) Protocol" [RFC7285], which includes a provision
   for only two modes:

   "numerical":  Indicates that numerical operations can be performed
      (e.g., normalization) on the returned costs (Section 6.1.2.1 of
      [RFC7285]).

   "ordinal":  Indicates that the cost values in a cost map represent
      ranking (relative to all other values in a cost map), not actual
      costs (Section 6.1.2.2 of [RFC7285]).

   Additional cost modes are required for specific ALTO deployment cases
   (e.g., [ALTO-PV]).  In order to allow for such use cases, this
   document relaxes the constraint imposed by the base ALTO
   specification on allowed cost modes (Section 3) and creates a new
   ALTO registry to track new cost modes (Section 5).

   The mechanisms defined in [RFC7285] are used to advertise the support
   of new cost modes for specific cost metrics.  Refer to Section 4 for
   more details.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   This document makes use of the terms defined in [RFC7285].

3.  Updates to RFC 7285


3.1.  Updates to Section 6.1.2 of RFC 7285

   This document updates Section 6.1.2 of [RFC7285] as follows:

   OLD:

      The cost mode attribute indicates how costs should be interpreted.
      Specifically, the cost mode attribute indicates whether returned
      costs should be interpreted as numerical values or ordinal
      rankings.

      It is important to communicate such information to ALTO clients,
      as certain operations may not be valid on certain costs returned
      by an ALTO server.  For example, it is possible for an ALTO server
      to return a set of IP addresses with costs indicating a ranking of
      the IP addresses.  Arithmetic operations that would make sense for
      numerical values, do not make sense for ordinal rankings.  ALTO
      clients may handle such costs differently.

      Cost modes are indicated in protocol messages as strings.

   NEW:

      The cost mode attribute indicates how costs should be interpreted.
      Two cost modes (numerical values and ordinal rankings) are
      defined, but additional cost modes can be defined in the future.

      It is important to communicate such information to ALTO clients,
      as certain operations may not be valid on certain costs returned
      by an ALTO server.  For example, it is possible for an ALTO server
      to return a set of IP addresses with costs indicating a ranking of
      the IP addresses.  Arithmetic operations that would make sense for
      numerical values, do not make sense for ordinal rankings.  ALTO
      clients may handle such costs differently.

      Cost modes are indicated in protocol messages as strings.

      For any future documents that defines a new cost mode, indicating
      whether that new cost mode applies to all or a subset of cost
      metrics is strongly recommended.  This recommendation is meant to
      prevent nondeterministic behaviors that may result in presenting a
      cost mode with a specific metric, while such an association does
      not make sense or can't be unambiguously interpreted by ALTO
      implementations.

      If the definition of a cost mode does not indicate whether that
      cost mode applies to a subset of cost metrics, ALTO
      implementations MUST be prepared to accept that cost mode for any
      cost metric.


3.2.  Updates to Section 10.5 of RFC 7285

   This document updates Section 10.5 of [RFC7285] as follows:

   OLD:

      A cost mode is encoded as a string.  The string MUST have a value
      of either "numerical" or "ordinal".

   NEW:

      A cost mode is encoded as a string.  The string MUST be no more
      than 32 characters, and it MUST NOT contain characters other than
      US-ASCII alphanumeric characters (U+0030-U+0039, U+0041-U+005A,
      and U+0061-U+007A), the hyphen-minus ('-', U+002D), the colon
      (':', U+003A), or the low line ('_', U+005F).  Cost modes reserved
      for Private Use are prefixed with "priv:" (Section 5).  Otherwise,
      the cost mode MUST have a value that is listed in the registry
      created in Section 5 of [RFC9274].


4.  Backward Compatibility Considerations

   ALTO servers that support new cost modes for specific cost metrics
   will use the mechanism specified in Section 9.2 of [RFC7285] to
   advertise their capabilities.  ALTO clients (including legacy) will
   use that information to specify cost constraints in their requests
   (e.g., indicate a cost metric and a cost mode).  An example of such a
   behavior is depicted in Section 9.2.3 of [RFC7285].

   If an ALTO client includes a cost mode that is not supported by an
   ALTO server, the server indicates such an error with the error code
   E_INVALID_FIELD_VALUE as per Section 8.5.2 of [RFC7285].  In
   practice, legacy ALTO servers will reply with the error code
   E_INVALID_FIELD_VALUE to requests that include a cost type other than
   "numerical" or "ordinal" for the "routingcost" cost metric.

   The encoding constraints in Section 3.2 do not introduce any
   interoperability issue given that currently implemented cost modes
   adhere to these constrains (mainly, those in [RFC7285] and
   [ALTO-PV]).

5.  IANA Considerations

   IANA has created the new "ALTO Cost Modes" subregistry within the
   "Application-Layer Traffic Optimization (ALTO) Protocol" registry
   available at [ALTO].

   The assignment policy for this subregistry is "IETF Review"
   (Section 4.8 of [RFC8126]).

   Requests to register a new ALTO cost mode must include the following
   information:

   Identifier:  The name of the ALTO cost mode.  Refer to Section 3.2
      for more details on allowed encoding.

   Description:  A short description of the requested ALTO cost mode.

   Intended Semantics:  A reference to where the semantic of the
      requested cost mode is defined.

   Reference:  A reference to the document that registers the requested
      cost mode.

   Cost modes prefixed with "priv:" are reserved for Private Use
   (Section 4.1 of [RFC8126]).  IANA has added the following note to the
   new subregistry:

   |  Identifiers prefixed with "priv:" are reserved for Private Use
   |  (see RFC 9274, Section 5).

   The subregistry is initially populated with the following values:

   +============+=============================+============+===========+
   | Identifier | Description                 | Intended   | Reference |
   |            |                             | Semantics  |           |
   +============+=============================+============+===========+
   | numerical  | Indicates that numerical    | Section    | RFC 9274  |
   |            | operations can be performed | 6.1.2.1    |           |
   |            | on the returned costs       | of         |           |
   |            |                             | [RFC7285]  |           |
   +------------+-----------------------------+------------+-----------+
   | ordinal    | Indicates that the cost     | Section    | RFC 9274  |
   |            | values in a cost map        | 6.1.2.2    |           |
   |            | represent ranking           | of         |           |
   |            |                             | [RFC7285]  |           |
   +------------+-----------------------------+------------+-----------+

                          Table 1: ALTO Cost Modes

6.  Security Considerations

   This document does not introduce new concerns other than those
   already discussed in Section 15 of [RFC7285].
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